Designing the case hierarchy
3 Tasks
1 hr 30 mins
Scenario
Metro Delivery Company (MDC) is a B2B company whose core business is delivering same-day Intracity shipments originating from registered business partners to their destination.
Analyze the key requirements for this application. The key requirements to consider are:
Processes
- Business partner registration to enable business partners to register with MDC.
- Truck vendor registration for partnerships with MDC to provide trucks for shipping.
- Delivery requests to enable business partners to request trucks to ship goods.
- Truck requests to accommodate the goods of business partners.
- Invoices to business partners to receive payments for registration, delivery service, and vendor payment.
Extensibility – these processes must be built to support extensibility to moving services.
Reporting – Reports on the number of products delivered by partner; profit reports need to be available.
Security – Data must be secured between the city managers and accountants.
Review all viable design options and list the pros and cons of each to produce a recommendation for the most appropriate case structure for the application.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks.
| Role | User name | Password |
|---|---|---|
| Admin | admin@deliveryservice | rules |
Detailed Tasks
1 Identify design options
Single case with subprocesses (subflows)
A single Delivery Request case cannot fulfil the process requirements due to case locking issues, which prevent multiple users from updating the case simultaneously. Although the extensibility and reporting requirements are easily met, and the User Interface (UI) requirement may be satisfied with independent data objects tracking each request, updating the status of each request requires extra work. Optimistic locking can solve the problem, but it may not be optimal as it could detract from the user experience during case processing.
Single case with child cases (subcases)
Another alternative is a Delivery Request top-level case with multiple instances of Truck Request subcases (depending on capacity). Each Truck Request can initiate an Invoice case. Modifying the default locking scheme to lock subcases independently of their parent solves the locking problem and allows parallel processing without interruption.
A hierarchical child case is not best practice because delivery requests are initiated by either a gold, silver, or bronze partner, the leftover capacity on a truck cannot be utilized because one truck request cannot be a child of another delivery request case initiated by a different partner.
Multiple cases (with subflows/processes)
A viable alternative is to create multiple top-level cases for delivery requests, truck requests, and invoice generation. Partner registration and vendor registration can be separate cases initiated by using a web embed from the MDC website. A delivery request case can initiate multiple instances of truck request cases depending on the capacity of the shipment. Each truck request can initiate an invoice.
Circumstanced top-level case (with subflows/processes)
A third alternative is to provide delivery partners with a self-service request feature, by using a web embed channel in the delivery request case circumstance. When the delivery partner places an order from the Place Order stage, it moves to Freight Fulfillment to place the truck request. This requires an additional screen to capture delivery partner details on the case and could be a security constraint too.
As such, this is not a suitable design.
2 Evaluate design options
Pros and cons of each design option
| Design | Pros | Cons |
|---|---|---|
| Single case with subprocesses (subflows) |
|
|
| Single case with child cases (subcases) |
|
|
| Multiple cases (with subflows/processes) |
|
|
| Circumstanced top-level case (with subflows/processes) |
|
|
3 Recommend the best design option
A delivery case with subcases is preferred because:
- MDC has multiple departments: Truck Management, Delivery Services, and a Finance Department. Creating different applications with cases for each application provides modularity and the applications can be run independently.
- Delivery request and truck request cases promote reusability and extensibility.
- Individual processes for different departments/LOBs can be established, making routing and approvals easy.
- Using web embeds for partner and vendor enrolments as separate cases.
- Application locking requirements should be considered.
- Each case offers more specialization options, making the application more accommodating of future requirements.
Confirm your work
Available in the following mission:
Want to help us improve this content?